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ABSTRACT 

Historical data and new findings from interviews with 
managers of major National Aeronautics and Space 
Administration (NASA) projects confirm literature 
reports about the criticality of the front-end phase of 
project development, where systems engineering plays 
such a key role. Recent research into the management of 
ten contemporary NASA projects, combined with 
personal experience of the author in NASA, provide 
some insight into the relevance and importance of the 
project manager in this initial part of the project life 
cycle. The research findings provide evidence of similar 
approaches taken by the NASA project manager. 

BACKGROUND 

Product development is project management. This 
paper addresses the product development cycle from a 
micro point of view of the definition phase of the 
product life-cycle before detailed design and develop- 
ment begins. This definition phase of the project cycle 
is sometimes called the "fuzzy front end" (Burkhart, 
1994). The decisions that are made in this phase move 
the product through morphology from its desired 
functionality into a (hopefully desired) product. 
However, similar to traveling from one point to another 
in a car, boat, or airplane, this phase can be difficult 
because there are any number of ways to get from here 
to there. Some ways of course are more efficient in both 
time and cost, and those are the most desirable 
alternatives to choose, unless you are simply out 
sightseeing. 

Figure l.is a generic product development cycle, 
sometimes called an inverted "bathtub" (Smallwood 
1973). The various curves in the figure show the 
relationship between investment spent, and income 
generated, with breakeven occurring some long time 
after the product is launched. The portion of the figure 
of interest here is the small part at the very far left of 
the figure, before product introduction. The purpose of 
focusing on this early portion of the cycle is because of 
its key importance to product development, and 
especially to overall product cost and development 
time. This very early stage of the product life-cycle is 
characterized by a relatively low rate of expenditure 
which allows for exploring multiple changes in product 
features with low cost penalties (Bacon et al., 1994). 
Paradoxically, the majority of the cost committed in 



Figure 1. Product Development Cycle 

new product development also occurs in this early part 
of the development cycle as shown in Figure 2. (Chase 
& Aquilano, 1995). 



Opportunity Window 


Figure 2. Product Cost Commitment 

It therefore seems intuitive that the emphasis in product 
development should be on spending time and money 
up-front when it will create the greatest benefit and 
result in the most significant cost savings. The 
National Aeronautics and Space Administration 
(NASA) found that this premise is indeed true in its 
projects. Figure 3.shows the comparison between cost 
overrun versus up-front investment studies on a number 
of past NASA projects (Hooks, 1994). 







The more spent early in a project life-cycle, the greater 
the opportunity for completing the project at, or near, 
the original cost. As shown in the figure, the optimum 
amount to allocate to early project definition studies 
appears to 10-15% of the project cost. 



Figure 4. Benefit of Study Phase Investment 


RESEARCH STUDY 

A recent investigation into the management of 
some contemporary NASA projects explored just how 
the project managers deals with this early front end of 
the project cycle. Tt must be kept in mind that NASA 
products are generally unique one-of-a-kind items, and 
therefore have neither the opportunity for, nor benefit 
of, follow-on changes after the product is launched. All 
reasonable action must therefore be taken to ensure that 
the single product developed will perform as desired at 
its first and often only debut. 

The management of complex projects is a tough job. 
As is evident from anecdotal evidence and in the 
literature (Gaddis 1959, Gadeken 1997), not everyone 
may have the necessary attributes to be a manager of 
complex projects. Much has been, and continues to be 
written about how product development projects should 
be managed, and how to manage them (Kerzner 1995, 
Wheelright & Clark 1992, Shtub et al. 1994). The use 
of interdisciplinary teams, team building, team 
dynamics and other managerial techniques is 
tremendously popular. The latest software, training 
courses, simulations, and other method-based tools are 
readily available, and of course useful. There continues 
to be however, a paucity of empirical information about 
what the project leader or manager brings to the project 
that results in a positive project outcome. This is 
especially true for complex, advanced technology 
projects where the project manager cannot, and probably 


must not, be the technical expert on the project. The 
review of ten recent, complex NASA projects provides 
some insight into the relevance and importance of how 
the project manager performs his/her role in complex 
NASA projects. 

The research study included several different types of 
NASA projects in a variety of technical disciplines 
within the four NASA enterprises of Space Science, 
Space Flight, Earth Science, and Aero-Space 
Technology as shown in Figure 5. The projects 
included in the study involved the development of 
space and planetary mission equipment, biomedical- 
research equipment, an advanced aeronautics wind 
tunnel facility, a launch vehicle, and aeronautical flight 
equipment development and test. 
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Figure 5. NASA Case-Study Projects 

The portion of the study described here focuses on the 
initial part of the project life cycle where the most 
benefits are to be gained as mentioned earlier. The 
project managers were interviewed about their projects 
to obtain first-hand information on how they managed 
the project, the project team, and outside influences. 
The findings indicate similar methodologies of use that 
present consistent patterns for the way these project 
managers manage their projects. Although these 
methodologies are similar, they are also extremely 
flexible to fit both the situation and the individual 
project manager. 

Establishing the Project How the project is 
established is important. One of the key issues 
addressed by the study participants was in formulating 
the project itself. Although the projects were very 
complex, each project was formulated based on simple 




principles. The key issues for the project manager 
included being involved early in the project, structuring 
the project in ways that were comfortable to them, 
establishing and articulating the project goal and 
success factors, and in selecting the project team. 
Figure 6. shows the important factors derived from the 
interviews for establishing the project. 
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IMPORTANT ISSUES 

Project 

Formulation 

Project 

requirements 

Detailed knowledge of 
requirements & project 
history 


Influence 

Ability to influence 
technical, cost, and schedule 
constraints of the project 

Project Goal 

Deliverables 

No ambiguity about what 
the project is to achieve 


Success Factors 

Identifies minimum 
necessary to meet the project 
goal 

Project 

Structure 

Personal 
strengths & 
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Fit to the project manager's 
strengths & weaknesses, & 
compatible with their 
preferred personal style for 
the project and situation 

Project Team 

Size 

Small increases visibility 
Tight control with no slack 
(extraneous roles) 


Key Members & 
Deputy 

Synergy with project 
manager's strengths and 
weaknesses 


Figure 6. Establishing the Project 

The particular requirements for each project defined the 
preferred project structure, and what the project 
managers chose to do themselves in structuring the 
project. The important technology areas involved and 
the driving forces of having to meet a fixed launch date 
or tight cost constraint focused the project manager's 
attention on the areas they felt were most important to 
the project outcome. They often chose to focus on 
particular items they were comfortable with such as the 
work-breakdown-structure (WBS), "I broke it down to 
the fourth level," or the budget, "I had a 300 element 
budget." Other approaches included innovating away 
from the standard practices of how-to-do project 
management, and organizing the projects in ways that 
mitigated risk; "I organized [my project] by [its] 
systems in a unique way." Whatever the choice of 
project structure that was chosen it was simple and fit 
the project manager's personal skill-set and their 
intuitive sense of what was needed in the particular 
situation they faced. 

The goal of the project was made crystal clear to the 
project team. Early involvement by the project manager 
provided an opportunity to understand the project goal 


and articulate it to the team. The goal was succinctly 
defined and made clear about why it was important to 
the project manager personally, to the team, to NASA, 
and in many cases to the world. Each project also had 
simply defined success factors with the science to be 
delivered always as the main product. 

The study participants were outspoken about the 
importance of choosing their key team members. 
Seven of the study project managers were able to 
choose their full-time team members, partly due to 
being involved in the early stages of the project's 
development, and partly because of their outright 
demand to do so. 

Smaller project teams are also better. The project 
managers preferred as small a team of full time 
members as possible. The reasons appeared to be a dual 
issue of both visibility of the project, and control. 
These project teams had no extraneous members or as 
one project manager stated it, "It was a no slack zone." 
The team members were placed in the few key roles 
established earlier by the project structure. The number 
of key team members ranged from 4 to 25 as shown in 
Figure 7. There was considerable variability in the 
complexities and types of technologies involved in the 
different projects that sometimes required more, and 
more diverse, technical specialists in some cases than in 
others. 
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Figure 7. Project Size Comparison 


Managing the Project. Beyond establishing the 
project in ways that fit their characteristics, there were 
general methods used in managing the study projects 
that became the framework for day-to-day operations. 
Defining clear roles for the key team members ensured 
that there was no duplication of effort. The small size 
of the teams allowed the project manager the visibility 
to ensure that all work was directed toward the project 
goal. The project goal and success factors not only 
defined what would be worked on, but also what would 
not be worked on. 


There were also few rules. Everyone on the project team 
knew his/her role. The project plan was to be followed 
and the minimum needed to accomplish the goal was 
the rule, but it would be done in a thorough and 
complete manner. It was made clear that the project 
manager was not the technical expert, and that the team 
specialists were both responsible and accountable for 
the technical issues. The project manager however, 
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No duplication 
of effort or 
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All work is directed 
toward the project goal 

Everyone knows his or 
her own role on the team 
and that of each other key 
person 

The project manager is 
not the technical expert on 
the project; the specialist 
team members are 
responsible and 
accountable for technical 
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The project manager is in 
charge of the project 

The project manager 
handles all nontechnical 
externa] contact with the 
project 

Few Rules 

No ambiguity 
about bow the 
project will 
operate 

A few, simple rules are 
established how the project 
would be managed 
- The project manager 
makes decisions when the 
team cannot reach 
consensus 

- The project manager 
makes all final decisions 
affecting project risk, 
budget, and/or schedule 

- Conflict is brought out 
and firmly dealt with 


Figure 8. General Management Methods 

ruled the budget and schedule. No technical changes 
were made that impacted these two, or that added risk 
to the project without involving his/her consent. The 
project manager handled all interactions outside of the 
project except for the technical issues that remained the 
responsibility of the technical specialist team members. 

SUMMARY 

Projects in NASA and in most of government and 
industry today need to move quickly from the 


functionality requirements to the reality of a product. 
Achieving good-and-fast decisions in the early phase of 
new product development demands the kind of project 
leadership that can make-it-happen. The managers of 
complex NASA projects provide that leadership and 
more. They recognize the need for early involvement in 
formulating the project through defining the project 
goal and success factors, careful structuring of the 
project, choosing the project team, and in establishing a 
few clear and simple guidelines for how the project will 
operate. They make-it-happen. 
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